In
many cases, you want to save or export the trace output generated by a
Profiler trace. The output can be analyzed, replayed, imported, or
manipulated at a later time after it has been saved. Trace output can be
saved as the trace is running or saved after it has been generated to
the Profiler GUI. The Trace Properties window provides options for
saving trace output while the trace is running. The options are defined
using the Save to File and Save to Table options on the General tab of
the Trace Properties window. You can save to a file, a table, or both a table and a file. Figure 1 shows an example of a trace that will save to both a file and table while it is executing.
Saving Trace Output to a File
When you save a running
trace to a file, you have several options for controlling the output.
One option you should always consider is the Set Maximum File Size (MB)
option. This option prevents a trace output file from exceeding the
specified size. Controlling the size
helps make the file more manageable and, more importantly, it can save
you from having a trace file gobble up all the disk space on the drive
you are writing to. Remember that the amount of trace data written to a
file on a busy production system can be extensive. You can also use this
file size option in conjunction with the Enable File Rollover option.
When the Enable File Rollover option is used, the trace does not stop
when the file size maximum is met. Instead, a new trace file is created,
and the output is generated to that file until it reaches the file size
maximum.
Saving Trace Output to a Table
The Save to Table option
writes the trace output directly to a SQL Server table as the trace is
running. Having the data in a SQL table provides a great deal of
flexibility for analyzing the data. You can use the full power of
Transact-SQL against the table, including sorting, grouping, and more
complex search conditions that are not available through the SQL
Profiler filters.
You need to consider both
the disk space requirements and impact on performance when the Save to
Table option is used. The Profiler provides an option, Set Maximum Rows
(in Thousands), to limit the amount of output generated from the trace.
The performance impact depends on the volume of data being written to
the table. Generally, you should avoid writing the trace output to a
table when using high-volume SQL servers. The best option for
high-volume servers is to first write the trace output to a file and
then import the file to a trace table at a later time.
Saving the Profiler GUI Output
Another option for saving
trace output occurs after trace output has been generated to the
Profiler GUI and the trace has been stopped. Similar to the save options
for an executing trace, the GUI output can be saved to a file or table.
You access the options to save the GUI output by selecting File, Save
As. The Trace File and Trace Table options are used to save to a file or
table consecutively. With SQL Server 2008, you can also save the output
to an XML file. The Trace XML File and Trace XML File for Replay
options generate XML output that can be edited or used as input for
replay with the SQL Server Profiler.
Note
Two distinct save operations
are available in the SQL Profiler. You can save trace events to a file
or table as just described, or you can save a trace definition in a
template file. The Save As Trace Table and Save As Trace File options
are for saving trace events to a file. The Save As Trace Template option
saves the trace definition. Saving a trace template saves you the
trouble of having to go through all the properties each time to set up
the events, data columns, and filters for your favorite traces.
An alternative to saving
all the event data associated with a particular trace is to select
specific event rows from the SQL Profiler windows. You can capture all
the trace information associated with a trace row by selecting a row in
the trace output window of Profiler and
choosing Edit, Copy. Or, you can just copy the event text (typically a
SQL statement) by selecting the row, highlighting the text in the lower
pane, and using the Copy option. You can then paste this data into SSMS
or the tool of your choice for further execution and more detailed
analysis. This capability can be particularly useful during performance
tuning. After you identify the long-running statement or procedure, you
can copy the SQL, paste it into SSMS, and display the query plan to
determine why the query was running so long.
Importing Trace Files
A trace saved to a file or table
can be read back into SQL Profiler at a later time for more detailed
analysis or to replay the trace on the same SQL Server or another SQL
Server instance. You can import data from a trace file or trace table by
choosing File, Open and then selecting either a trace file or trace
table. If you choose to open a trace file, you are presented with a
dialog to locate the trace file on the local machine. If you choose to
import a trace table, you are first presented with a connection dialog
to specify the SQL Server name, the login ID, and the password to
connect to it. When you are successfully connected, you are presented
with a dialog to specify the database and name of the trace table you
want to import from. After you specify the trace file or trace table to
import into Profiler, the entire contents of the file or table are read
in and displayed in a Profiler window.
You may find that large
trace files or trace tables are difficult to analyze, and you may just
want to analyze events associated with a specific application or table,
or specific types of queries. To limit the amount of information
displayed in the Profiler window, you can filter out the data displayed
via the Properties dialog. You can choose which events and data columns
you want to display and also specify conditions in the Filters tab to
limit the rows displayed from the trace file or trace table. These
options do not affect the information stored in the trace file or trace
table—only what information is displayed in the Profiler window.
Importing a Trace File into a Trace Table
Although you can load a trace
file directly into Profiler for analysis, very large files can be
difficult to analyze. Profiler loads an entire file. For large files,
this process can take quite awhile, and the responsiveness of Profiler
might not be the best. Multiple trace output files for a given trace can
also be cumbersome and difficult to manage when those files are large.
You can use the trace
filters to limit which rows are displayed but not which rows are
imported into Profiler. You often end up with a bunch of rows displayed
with no data in the columns you want to analyze. In addition, while the
filters allow you to limit which rows are displayed, they don’t really
provide a means of running more complex reports on the data, such as
generating counts of events or displaying the average query duration.
Fortunately, SQL Server 2008
provides a way for you to selectively import a trace file into a trace
table. When importing a trace file into a trace table, you can filter
the data before it goes into the table as well as combine multiple files
into a single trace table. When the data
is in a trace table, you can load the trace table into Profiler or
write your own queries and reports against the trace table for more
detailed analysis than is possible in Profiler.
Microsoft SQL Server also includes some built-in user-defined functions for working with Profiler traces. The fn_trace_gettable function is used to import trace file data into a trace table. Following is the syntax for this function:
fn_trace_gettable( [ @filename = ] filename , [ @numfiles = ] number_files )
Listing 1. Creating and Inserting Trace Data into a Trace Table from a Trace File
/********************************************************************
** NOTE - you will need to edit the path/filename on your system if
** you use this code to load your own trace files
*********************************************************************/
select EventClass,
EventSubClass,
TextData = convert(varchar(8000), TextData),
BinaryData,
ApplicationName,
Duration,
StartTime,
EndTime,
Reads,
Writes,
CPU,
ObjectID,
IndexID,
NestLevel
into TraceTable
FROM ::fn_trace_gettable('c:\temp\sampletrace_ 20090510_0622.trc', default)
where TextData is not null
or EventClass in (16, — Attention
25, — Lock:Deadlock
27, — Lock:Timeout
33, — Exception
58, — Auto Update Stats
59, — Lock:Deadlock Chain
79, — Missing Column Statistics
80, — Missing Join Predicate
92, — Data File Auto Grow
93, — Log File Auto Grow
94, — Data File Auto Shrink
95) — Log File Auto Shrink
Insert into TraceTable (EventClass, EventSubClass,
TextData, BinaryData,
ApplicationName, Duration, StartTime, EndTime, Reads, Writes,
CPU, ObjectID, IndexID, nestlevel)
select EventClass, EventSubClass,
TextData = convert(varchar(7900), TextData), BinaryData,
ApplicationName, Duration, StartTime, EndTime, Reads, Writes,
CPU, ObjectID, IndexID, nestlevel
FROM ::fn_trace_gettable('c:\temp\sampletrace_ 20090510_0205.trc', -1)
where TextData is not null
or EventClass in (16, — Attention
25, — Lock:Deadlock
27, — Lock:Timeout
33, — Exception
58, — Auto Update Stats
59, — Lock:Deadlock Chain
79, — Missing Column Statistics
80, — Missing Join Predicate
92, — Data File Auto Grow
93, — Log File Auto Grow
94, — Data File Auto Shrink
95) — Log File Auto Shrink
go
|
After the trace file is imported
into a trace table, you can open the trace table in Profiler or run
your own queries against the trace table from a query editor window in
SSMS. For example, the following query returns the number of lock
timeouts encountered for each table during the period the trace was
running:
select object_name(ObjectId), count(*)
from TraceTable
where EventClass = 27 — Lock:Timout Event
group by object_name(ObjectId)
go
Analyzing Trace Output with the Database Engine Tuning Advisor
In
addition to being able to manually analyze traces in Profiler, you can
also use the Database Engine Tuning Advisor to analyze the queries
captured in a trace and recommend changes to your indexing scheme. The
Database Engine Tuning Advisor is a replacement for the Index Tuning
Wizard that was available in SQL Server 2000. You can invoke it from the
Tools menu in SQL Profiler. The Database Engine Tuning Advisor can read
in a trace that was previously saved to a table or a file. This feature
allows you to capture a workload, tune the indexing scheme, and re-run
the trace to determine whether the index changes improved performance as
expected.
Because the Database
Engine Tuning Advisor analyzes SQL statements, you need to make sure
that the trace includes one or more of the following events:
SP:StmtCompleted
SP:StmtStarting
SQL:BatchCompleted
SQL:BatchStarting
SQL:StmtCompleted
SQL:StmtStarting
One of each class (one SP: and one SQL:)
is sufficient to capture dynamic SQL statements and statements embedded
in stored procedures. You should also make sure that the trace includes
the text data column, which contains the actual queries.
The Database Engine Tuning
Advisor analyzes the trace and gives you recommendations, along with an
estimated improvement-in-execution time. You can choose to create
indexes now or at a later time, or you can save the CREATE INDEX commands to a script file.
